SGI Varsity Update 1998 August

home *** CD-ROM | disk | FTP | other *** search

/ SGI Varsity Update 1998 August / SGI Varsity Update 1998 August.iso / docs6.4 / relnotes / pcp / ch3.z / ch3

Wrap

Text File | 1998-07-29 | 33KB | 776 lines

- 1 - 3. _C_h_a_n_g_e_s__a_n_d__A_d_d_i_t_i_o_n_s The major additions and changes for the basic services and tools of the Performance Co-Pilot are described in the following sections. Unless otherwise stated, all changes describe PCP 2.0 relative to the prior PCP 1.3 release. Refer to the reference pages of the individual utilities for a complete description of any new functionality. 3.1 _I_n_f_r_a_s_t_r_u_c_t_u_r_e__C_h_a_n_g_e_s The following changes have been made to the PCP infrastructure that affect both collector and monitor configurations. 1. The PCP Performance Metrics Name Space (PMNS) has previously been local to the application wishing to make reference to PCP metrics by name. In PCP 2.0 the PMNS operations are directed to the host or archive that is the source of the desired performance metrics, see ppppmmmmnnnnssss(4). The default name space is now associated with the PCP collector host rather than PCP monitor host. The distributed PMNS involves changes to both the PCP protocols between client applications and ppppmmmmccccdddd, and the internal format of PCP archive files (the ppppmmmmllllooooggggggggeeeerrrr(1) utility is able to write PCP archive logs in either the old or new formats). 2. PCP monitor hosts do not require any name space files, unless the local PCP client applications need to connect to PCP collector hosts that have not yet been upgraded to PCP 2.0. The distributed PMNS is implemented by having the name space functions of the PCP Performance Metrics Application Programming Interface (PMAPI) send and receive messages to and from the collector ppppmmmmccccdddd(1), just like the other PMAPI functions. 3. Full interoperability is supported for PCP 2.0, so new PCP components will operate correctly with either new or old PCP components. For example, a PCP client that connects to a PCP 1.x ppppmmmmccccdddd or attempts to process a PCP archive created by a PCP 1.x ppppmmmmllllooooggggggggeeeerrrr will revert to using the local PMNS. The following table describes the supported interoperability between the client, ppppmmmmccccdddd(1) and PCP archive log components of PCP 2.0 and PCP 1.x: - 2 - ___________________________________________________ PCP 1.x client PCP 2.0 client ______________________________________________________________________________________________________ PCP 1.x _p_m_c_d yes yes PCP 1.x archive yes yes PCP 2.0 _p_m_c_d yes yes PCP 2.0 archive no yes ___________________________________________________ |||||| |||||||||||| |||||| |||||| 4. The protocols between a PMDA and ppppmmmmccccdddd(1) have also changed, through a new version of the _l_i_b_p_c_p__p_m_d_a library. The following table describes the supported interoperability between the ppppmmmmccccdddd(1) and PMDA components of PCP 2.0 and PCP 1.x: ________________________________________________________________ PCP 1.x PCP 1.x PCP 2.0 PCP 2.0 daemon PMDA DSO PMDA daemon PMDA DSO PMDA ________________________________________________________________________________________________________________________________ PCP 1.x _p_m_c_d yes yes no no PCP 2.0 _p_m_c_d yes no yes yes ________________________________________________________________ ||||| |||||||||| ||||| ||||| ||||| ||||| 5. Product structural changes. The PCP product images have been re-arranged as follows. +o _p_c_p__e_o_e contains all of the pieces that are common to any successful PCP installation, particularly for a collector system, i.e. a place where ppppmmmmccccdddd is running. +o _p_c_p__e_o_e will ship in IRIX 6.5 and as part of PCP 2.0 for earlier IRIX releases. +o _p_c_p__e_o_e._s_w._m_o_n_i_t_o_r includes the oooovvvviiiieeeewwww monitoring application (for monitoring the performance of ORIGIN systems, from SC4-PCPORIGIN) and does not require any PCP licenses. +o _p_c_p._s_w._b_a_s_e provides the core PCP components that are outside _p_c_p__e_o_e. +o _p_c_p._s_w._e_o_e for IRIX 6.2 or later has been replaced by _p_c_p__e_o_e._s_w._e_o_e (more formally the latter updates the former). For IRIX 5.3, _p_c_p._s_w._e_o_e is almost empty, but allows for clean upgrades from all earlier PCP versions. +o _p_c_p._s_w._m_o_n_i_t_o_r provides all of the PCP client tools for monitoring performance. - 3 - +o The other _p_c_p subsystems provide optional PCP components. 6. PCP 2.0 introduces some new extensions to the PMAPI, mostly to accommodate the distributed PMNS and some underlying protocol changes to support enhanced inter-operability. The _l_i_b_p_c_p and _l_i_b_p_c_p__p_m_d_a libraries have been updated to version sgi2.0. The older versions of these libraries are still supported and may be installed from the _p_c_p._s_w._c_o_m_p_a_t subsystem if required for older PMDAs or customer-developed PCP applications. The API has also changed in some ways related to symbol hiding and changes in function arguments. The xxxxllllaaaatttteeee____ppppmmmmaaaappppiiii script in the _p_c_p__g_i_f_t_s._s_w._m_i_g_r_a_t_e subsystem may be used to automate the bulk of the source code translation from the 1.x version to the 2.0 version of the PMAPI, i.e. from _l_i_b_p_c_p._s_o._1 and _l_i_b_p_c_p__p_m_d_a._s_o._1 to _l_i_b_p_c_p._s_o._2 and _l_i_b_p_c_p__p_m_d_a._s_o._2. 7. In the transition from PCP 1.2 to PCP 1.3, the _l_i_b_p_c_p__l_i_t_e library was removed and the functionality replaced by the new PPPPMMMM____CCCCOOOONNNNTTTTEEEEXXXXTTTT____LLLLOOOOCCCCAAAALLLL option to ppppmmmmNNNNeeeewwwwCCCCoooonnnntttteeeexxxxtttt(3) in _l_i_b_p_c_p. The old _l_i_b_p_c_p__l_i_t_e library is still available in the _p_c_p._s_w._c_o_m_p_a_t subsystem. 8. ppppmmmmLLLLooooooookkkkuuuuppppNNNNaaaammmmeeee(3) now produces an extra error code, PPPPMMMM____EEEERRRRRRRR____NNNNOOOONNNNLLLLEEEEAAAAFFFF which means that the given name refers to a non-leaf node in the PMNS and so no PMID can be returned. Previously, if a non-leaf name was given then PPPPMMMM____EEEERRRRRRRR____NNNNAAAAMMMMEEEE would be returned. Now the error PPPPMMMM____EEEERRRRRRRR____NNNNAAAAMMMMEEEE means only that the name does not exist in the name space. 9. The function ppppmmmmGGGGeeeettttCCCChhhhiiiillllddddrrrreeeennnnSSSSttttaaaattttuuuussss(3) was added to the PMAPI. It was introduced mainly to satisfy a new need of ppppmmmmcccchhhhaaaarrrrtttt(1). As well as getting the names of all the children nodes, ppppmmmmGGGGeeeettttCCCChhhhiiiillllddddrrrreeeennnnSSSSttttaaaattttuuuussss returns a parallel array of the status of each node, indicating if it is a leaf or non-leaf node. 10. A new (much smaller) format for PMDA help text files has been implemented, with support in the _l_i_b_p_c_p__p_m_d_a library and the nnnneeeewwwwhhhheeeellllpppp(1) utility. 11. A ----LLLL option was added to ppppmmmmdddduuuummmmpppplllloooogggg(1) to produce a more verbose variant of ----llll and report all of the details from a PCP archive label. - 4 - 12. ppppmmmmllllooooggggggggeeeerrrr(1) uses the additional ppppmmmmccccdddd state change information to embed "mark" records in PCP archives when new PMDAs are started by ppppmmmmccccdddd. During replay, this prevents interpolation of values in the PCP archive across the life of an old and a new instance of the same PMDA. 13. The archive logger management scripts ccccrrrroooonnnn....ppppmmmmddddaaaaiiiillllyyyy(1), ccccrrrroooonnnn....ppppmmmmcccchhhheeeecccckkkk(1), ccccrrrroooonnnn....ppppmmmmllllooooggggmmmmeeeerrrrggggeeee(1), ccccrrrroooonnnn....ppppmmmmssssnnnnaaaapppp(1) and ppppmmmmnnnneeeewwwwlllloooogggg(1) have been re-worked to: +o Reduce their verbosity and hence mail from ccccrrrroooonnnn(1M) when they are run in production environments. +o Add new options ----VVVV and ----NNNN allow verbose reporting, and "show-me" mode in which actions are reported but not performed. +o Support mutually exclusive locking to prevent concurrent execution in the same directory. +o Allow multiple ppppmmmmllllooooggggggggeeeerrrr instances for the same host to be managed concurrently. 14. The temporal index file (``.index'' suffix) is optional when PCP archives are being replayed. 15. Changes to track the object format of the booted IRIX kernel, briefly: +o ``MACH'' tag key PCP binaries in the images to ensure installation of o32, n32 or n64 versions as appropriate, based upon the installation platform and the IRIX version. +o Only one version of the ppppmmmmccccdddd binary will be installed, now in /_u_s_r/_e_t_c/_p_m_c_d. +o A new ppppmmmmoooobbbbjjjjssssttttyyyylllleeee(1) command is used to determine the appropriate kernel object style at run time as required, e.g. when ppppmmmmccccdddd(1) is attaching a DSO PMDA. 3.2 _C_o_l_l_e_c_t_o_r__C_h_a_n_g_e_s The following changes effect PMCD and the PMDAs that provide the collection services. 1. ppppmmmmccccdddd(1) has been modified to support the distributed name space. This has meant the following changes: - 5 - +o ppppmmmmccccdddd(1) now loads the default name space on startup or an alternative name space if specified by ----nnnn. +o On a SIGHUP signal it will reload the name space if it has been modified since the last load time. +o ppppmmmmccccdddd(1) responds to name space PDU requests using its local name space. 2. ppppmmmmccccdddd(1) no longer requires a PCP collector license to start, however connections will be refused for most PCP clients unless the PCP collector license is installed and valid. Some clients (most notably oooovvvviiiieeeewwww(1)) can connect to ppppmmmmccccdddd independent of any PCP licenses. To support this, the client-pmcd connection protocols have been extended. 3. Support has been added for multiple protocol versions for the client-pmcd IPC and the interaction between ppppmmmmccccdddd and the PMDAs. 4. The logic used by ppppmmmmccccdddd for locating DSO PMDAs of the correct object format has been reworked. 5. The diagnostic event tracing options of ppppmmmmccccdddd have been extended to include an "unbuffered" mode where every event is reported as it happens, as opposed to buffering events in a ring buffer and only reporting on errors and in response to explicit requests. 6. The distributed PMNS changes mean that ppppmmmmccccdddd must load and export the PMNS in response to requests from client applications. ppppmmmmccccdddd's SIGHUP processing has been extended to include reloading the PMNS if the external PMNS file has been modified. 7. In concert with a change to ppppmmmmFFFFeeeettttcccchhhh in _l_i_b_p_c_p, ppppmmmmccccdddd is now able to export out-of-band information about ppppmmmmccccdddd state changes (specifically PMDA add, drop and restart) back to client applications. 8. The sssshhhhppppiiiinnnngggg PMDA has been enhanced with additional services to be monitored with the default configuration. ppppmmmmggggsssshhhhppppiiiinnnngggg(1) is a new ppppmmmmggggaaaaddddggggeeeettttssss(1) front-end for monitoring the availability and quality of service (response-time) for the services being monitored by the sssshhhhppppiiiinnnngggg PMDA. - 6 - 9. The ppppmmmmccccdddd PMDA supports a new pmcd.control.sighup metric may be used with ppppmmmmssssttttoooorrrreeee(1) to simulate a SIGHUP to ppppmmmmccccdddd. 10. The ttttrrrraaaacccceeee PMDA and the _l_i_b_p_c_p__t_r_a_c_e library combine to provide a new mechanism for integrating application level instrumentation into the PCP framework. The ttttrrrraaaacccceeee PMDA aggregates event counts and event service times from applications instrumented using the API of _l_i_b_p_c_p__t_r_a_c_e. See ppppmmmmddddaaaattttrrrraaaacccceeee(1), ppppmmmmttttrrrraaaacccceeeebbbbeeeeggggiiiinnnn(3) and the ttttrrrraaaacccceeee PMDA section of the PCP Tutorial (from the _p_c_p._m_a_n._t_u_t_o_r_i_a_l subsystem). 11. The hhhhoooottttpppprrrroooocccc PMDA is a new agent for monitoring unusual process activity. The features of this PMDA include: +o Allowing a user-defined set of ``interesting'' processes to be efficiently monitored. +o The ``interesting'' set is periodically re- evaluated. +o The criteria used to define ``interesting'' include expressions over CPU burn rate, uid/uname, gid/gname, process name, psargs, iodemand, ctxswitch, syscalls, virtualsize, residentsize, iowait and schedwait. +o It is expected that this PMDA will provide a PCP-compatible and more efficient replacement for ttttoooopppp(1), particularly for systems with a large number of active processes. 12. The mmmmaaaaiiiillllqqqq PMDA is a new agent to monitor the length of the sendmail queue, and histogram bin the mail items based on length of time in the queue. 3.3 _M_o_n_i_t_o_r__C_h_a_n_g_e_s The major additions and changes for the performance visualization and analysis tools are described below. 1. Monitor applications no longer use the local default name space to get PMIDs for metric names unless the name space file is explicitly given as a ----nnnn option or the target ppppmmmmccccdddd, specified by ----hhhh, is a lower revision than PCP 2.0. Monitor applications use the distributed name space by sending PDU requests to - 7 - ppppmmmmccccdddd. 2. To convert an existing user-written monitor application to use the distributed name space, the following must be done: +o Only call ppppmmmmLLLLooooaaaaddddNNNNaaaammmmeeeeSSSSppppaaaacccceeee(3) in the case of being given a ----nnnn option to specify a particular name space file. If one only wants to use the distributed name space then the call to ppppmmmmLLLLooooaaaaddddNNNNaaaammmmeeeeSSSSppppaaaacccceeee(3) can be deleted altogether. As soon as ppppmmmmLLLLooooaaaaddddNNNNaaaammmmeeeeSSSSppppaaaacccceeee(3) is called, the application is in local name space mode. +o All calls to the PMAPI name space functions must be made in a current PMAPI context. Previously, since a context was not used to service name space functions, it was possible to call these functions before any new context was created. Now, if there is no current PMAPI context and ppppmmmmLLLLooooaaaaddddNNNNaaaammmmeeeeSSSSppppaaaacccceeee(3) has not previously been called when a name space function is called an error code will be returned. +o The calls to the PMAPI name space functions (in distributed mode) will take longer to execute (as they must send/receive a PDU to/from a remote ppppmmmmccccdddd). This means that the name space calls should not be made unnecessarily. +o All name space calls should be tested for failure. This was, of course, always the case, but previously there was more chance that one could get away without testing some calls for failure. However, now, every call could have some failure due to problems with sending or receiving a PDU. 3. ppppmmmmcccchhhhaaaarrrrtttt(1) is a good example of the effects of a distributed name space. By selecting different hosts in the metric viewer window, one can see the different metrics in their respective name spaces and hence the different agents which are likely to be installed on those hosts (providing the hosts have PCP 2.0 installed). 4. There is a new ppppccccpppp(1) application that reports the details of the current PCP installation. The ppppccccpppp(1) man page points to PCP services and features and cross-references PPPPCCCCPPPPIIIInnnnttttrrrroooo(1) which is a - 8 - new man page repository for general information about PCP terms, command line options, environment variables, etc. 5. The oooovvvviiiieeeewwww(1) application for monitoring Origin 200 and Origin 2000 systems has migrated from the SC4- PCPORIGIN product and is now included in the _p_c_p__e_o_e._s_w._m_o_n_i_t_o_r subsystem. This application is unlicensed and will operate with an unlicensed ppppmmmmccccdddd(1). 6. Many of the GUI PCP tools have been integrated into the IRIX Interactive Desktop environment, including launch by icon, drag-n-drop behavior for hosts or archives dropped onto PCP tools and a new ppppmmmmrrrruuuunnnn(1) command to support optional command line arguments for PCP tools launched from the desktop. 7. A PPPPeeeerrrrffffTTTToooooooollllssss page in the Icon Catalog has been created for launching PCP tools. 8. The handling of error messages for both GUI and command-line invocations of most tools has been unified and made more consistent. 9. The ppppmmmmttttiiiimmmmeeee(1) application that provides time control services to other PCP tools has been enhanced in a number of ways: +o A new Archive Time Bounds dialog (available only in archive mode) allows time window bounds to be constrained or expanded at run-time (particularly useful when replaying archives that are still growing). +o Extensions to the ppppmmmmttttiiiimmmmeeee client protocol to allow clients to force VCR state changes and alter the time window bounds. +o The ppppmmmmttttiiiimmmmeeee protocol is nnnnooootttt backwards compatible with the PCP 1.x implementation, but all clients of ppppmmmmttttiiiimmmmeeee are re-released with the images on the PCP 2.0 CD and both ppppmmmmttttiiiimmmmeeee and its clients execute on the same system. 10. The ppppmmmmkkkkssssttttaaaatttt(1) command has been restructured in the wake of _l_i_b_p_c_p__l_i_t_e's demise, and in particular a new ----LLLL option supports stand alone use without ppppmmmmccccdddd(1). 11. Changes to ppppmmmmcccchhhhaaaarrrrtttt(1) include: - 9 - +o Improved Metric Information Dialog to display multiple metrics from the same plot and to optionally update in real-time to report the most recently observed values. +o Revised "record-mode" behavior for real-time archive creation. +o Improved axis labelling in respect of time resolution and Y-axis units selection. +o Save image in GIF format. +o Regular expression matching for instances in View specifications. +o Views may be saved as Host Dynamic (or Host Literal). +o Window geometry saved with View specification. +o Better desktop integration for host and PCP archive selection. +o Optional chart titles. +o Enhanced and expanded collections of standard Views. 12. The ppppmmmmvvvviiiieeeewwww(1) application has been re-implemented using new internal libraries with new features, while preserving backwards compatibility for the old scene description language. Changes include: +o Revised "record-mode" behavior for real-time archive creation. +o Improved scene configuration options. +o Improved launch (drill-down) behavior. +o Support for selection of multiple objects in the scene. +o New object types including color modulated bars and cylinders. +o Rewording of the text box annotation to use "expected max" to describe the height scaling. - 10 - +o New front-ends: oooossssvvvviiiissss(1) and xxxxbbbboooowwwwvvvviiiissss(1). +o Front-ends nnnnooooddddeeeevvvviiiissss(1) and rrrroooouuuutttteeeerrrrvvvviiiissss(1) from PCPORIGIN incorporated in the PCP product. 13. Previously ppppmmmmiiiieeee(1) required a valid PCP Monitor license, now ppppmmmmiiiieeee may be run provided either a valid PCP Monitor license or a valid PCP Collector license is available. 14. ppppssssmmmmoooonnnn(1) is a new utility designed for generalized process-level monitoring, including the ability to launch PCP tools (e.g. ppppmmmmcccchhhhaaaarrrrtttt and ppppmmmmllllooooggggggggeeeerrrr) targeted at a specific set of processes. 15. The new utility ppppmmmmllllooooggggeeeexxxxttttrrrraaaacccctttt(1) replaces ppppmmmmllllooooggggmmmmeeeerrrrggggeeee(1). In addition to subsuming of the services of ppppmmmmllllooooggggmmmmeeeerrrrggggeeee, ppppmmmmllllooooggggeeeexxxxttttrrrraaaacccctttt also supports: +o Additional ``slice-n-dice'' options for extracting information from PCP archive logs. +o Options ----zzzz and ----ZZZZ added to control interpretation of the timezone, particularly for use with ----SSSS and ----TTTT options. Timezone handling now the same as other PCP tools, namely defaults to the local timezone in the absence of ----zzzz or ----ZZZZ, compared to the former behavior of ppppmmmmllllooooggggmmmmeeeerrrrggggeeee which implicitly and unconditionally used the timezone of the input archives. 16. The ppppmmmmdddduuuummmmpppptttteeeexxxxtttt(1) application generates ASCII output for multiple metrics and/or multiple sources of metrics. Rewritten from the earlier ``gift'' version. Revised ppppmmmmdddduuuummmmppppmmmmiiiinnnneeeesssseeeetttt(1) wrapper to produce data suitable for loading into MineSet. 17. ppppmmmmggggcccciiiissssccccoooo(1) is a new ppppmmmmggggaaaaddddggggeeeettttssss(1) front-end for monitoring interface activity for Cisco routers using the data exported by the cccciiiissssccccoooo PMDA. - 11 - 3.4 _F_e_a_t_u_r_e_s__R_e_m_o_v_e_d__o_r__D_e_p_r_e_c_a_t_e_d In PCP 2.0, the following features from earlier PCP versions have been removed. 1. The original intent in the Performance Co-Pilot framework was to support seamless VCR-replay between a current ``live'' source and a recently created archive source. In practice, the semantic and operational difficulties associated with transitions between ``live'' and ``archive'' modes are so significant that the feature has been abandoned. Earlier PCP releases included a ``stubbed-out'' application ppppmmmmvvvvccccrrrr(1) that did not really do anything and assorted infrastructure ``hooks''. These have been removed. 2. _l_i_b_p_c_p__l_i_t_e._s_o - replaced by PPPPMMMM____CCCCOOOONNNNTTTTEEEEXXXXTTTT____LLLLOOOOCCCCAAAALLLL The standalone (without ppppmmmmccccdddd) library _l_i_b_p_c_p__l_i_t_e._s_o has been replaced by the PPPPMMMM____CCCCOOOONNNNTTTTEEEEXXXXTTTT____LLLLOOOOCCCCAAAALLLL option to the ppppmmmmNNNNeeeewwwwCCCCoooonnnntttteeeexxxxtttt(3) routine. The following features and services are supported in PCP 2.0, but the intention is to remove them in a future PCP version. 1. ASCII mode PDUs and the PPPPDDDDUUUU____AAAASSSSCCCCIIIIIIII argument to ppppmmmmNNNNeeeewwwwCCCCoooonnnntttteeeexxxxtttt(3). To the best of our knowledge, nothing but the ``toy'' demonstration PMDA news agent has ever used this. The current PCP libraries (in particular _l_i_b_p_c_p__p_m_d_a and _l_i_b_p_c_p__t_r_a_c_e) make building a real PMDA less effort than fighting with the ACSII PDUs in a sssshhhh(1) script.